feat: add bulk scope support to PUT /api/authz/v1/roles/users/ by ccantillo · Pull Request #256 · openedx/openedx-authz

ccantillo · 2026-04-13T15:59:30Z

Description

Adds bulk scope support to the existing PUT /api/authz/v1/roles/users/ endpoint.

Previously, the endpoint only accepted a single scope string, requiring one request per scope when assigning a role across multiple scopes. This change introduces a new scopes list field that allows assigning a role to one or more users across multiple scopes in a single request.

Closes #231

Changes

AddUsersToRoleWithScopeSerializer: made scope optional and added a scopes list field. The validate() method normalizes both formats into a unified scopes list, validating existence and role availability for every scope.
RoleUserAPIView.put(): updated to iterate over data["scopes"], including a scope field in every completed/error response entry.
Tests: added cases for multi-scope payloads, single-scope via scopes field, rejection of ambiguous inputs (both/neither field provided), and verification that response entries carry the scope field.

Backward Compatibility

The existing scope (single string) field continues to work exactly as before. Existing clients are unaffected — the only additive change to the response is a scope field on each entry.

Old payload (still supported):

{
  "users": ["contributor"],
  "role": "library_author",
  "scope": "lib:WGU:CSPROB"
}

New payload:

{
  "users": ["contributor"],
  "role": "library_author",
  "scopes": ["lib:WGU:CSPROB", "lib:WGU:OTHER"]
}

Response (both formats):

{
  "completed": [
    {"user_identifier": "contributor", "scope": "lib:WGU:CSPROB", "status": "role_added"},
    {"user_identifier": "contributor", "scope": "lib:WGU:OTHER", "status": "role_added"}
  ],
  "errors": []
}

openedx-webhooks · 2026-04-13T15:59:37Z

Thanks for the pull request, @ccantillo!

This repository is currently maintained by @openedx/committers-openedx-authz.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

Dependencies

This PR must be merged before / after / at the same time as ...
Blockers

This PR is waiting for OEP-1234 to be accepted.
Timeline information

This PR must be merged by XX date because ...
Partner information

This is for a course on edx.org.
Supporting documentation
Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

The size and impact of the changes that it introduces
The need for product review
Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

mariajgrimaldi

Thanks so much for this! I left a few comments for you to review.

Mainly, I'd like to understand why this API needs to be backward compatible. I think we are still in the early stages of the framework, so making things backward-compatible might just make it more complex for us to maintain going forward. Just a note to consider.

FYI @rodmgwgu

ccantillo · 2026-04-14T15:49:05Z

Thanks so much for this! I left a few comments for you to review.

Mainly, I'd like to understand why this API needs to be backward compatible. I think we are still in the early stages of the framework, so making things backward-compatible might just make it more complex for us to maintain going forward. Just a note to consider.

FYI @rodmgwgu

Thanks for the review. The issue #231 states "keep backwards compatibility", so that's a requirement rather than a design choice on my end. That said, it's a fair point to raise. if @rodmgwgu agrees we can break it

bmtcril

Looks good to me. I don't know enough about the frontend impl to say whether maintaining backwards compatibility would save FE developer time at this point but that may have been a reason why it was in the requirements

rodmgwgu · 2026-04-14T20:56:06Z

Thanks so much for this! I left a few comments for you to review.
Mainly, I'd like to understand why this API needs to be backward compatible. I think we are still in the early stages of the framework, so making things backward-compatible might just make it more complex for us to maintain going forward. Just a note to consider.
FYI @rodmgwgu

Thanks for the review. The issue #231 states "keep backwards compatibility", so that's a requirement rather than a design choice on my end. That said, it's a fair point to raise. if @rodmgwgu agrees we can break it

I specified keeping backwards compatibility to avoid breaking the existing libraries team management view in the admin dashboard, mostly so we don't have a broken state while the new frontend view is fully implemented and merged.

rodmgwgu

Looking good, please update the CHANGELOG and version.

ccantillo · 2026-04-16T17:40:01Z

Looking good, please update the CHANGELOG and version.

Done! Bumped the version and added the entry to the CHANGELOG.

rodmgwgu · 2026-04-16T17:41:58Z

Looking good, please update the CHANGELOG and version.

Done! Bumped the version and added the entry to the CHANGELOG.

Thanks!, it seems there are some conflicts yet caused by other merges, sorry for that. Can you update that please?

Accept a new list field alongside the existing string, allowing role assignment across multiple scopes in one request while keeping full backward compatibility. Each response entry now includes a field.

…rializer

…copeValidationMixin

ccantillo · 2026-04-16T17:54:38Z

Thanks!, it seems there are some conflicts yet caused by other merges, sorry for that. Can you update that please?

Done! Conflicts resolved and branch updated

dwong2708 · 2026-04-16T18:03:10Z

+            for user_identifier in data["users"]:
+                response_dict = {"user_identifier": user_identifier, "scope": scope_value}
+                try:
+                    user = get_user_by_username_or_email(user_identifier)


Just a question: what happens if the user is not activated? Should we assign them a role?

That's a good question, in this case, this logic already existed and we don't have a specific requirement for this, perhaps we should create a tech debt issue to review this.

Got it. Thanks

rodmgwgu

Thanks for attending this, LGTM!

dwong2708

LGTM. Thanks

Made-with: Cursor

mariajgrimaldi

Thanks for addressing all my comments!

ccantillo requested a review from mariajgrimaldi April 13, 2026 15:59

openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Apr 13, 2026

openedx-webhooks added this to Contributions Apr 13, 2026

github-project-automation Bot moved this to Needs Triage in Contributions Apr 13, 2026

mariajgrimaldi requested changes Apr 14, 2026

View reviewed changes

Comment thread openedx_authz/rest_api/v1/serializers.py

Comment thread openedx_authz/rest_api/v1/serializers.py Outdated

Comment thread openedx_authz/rest_api/v1/serializers.py Outdated

mariajgrimaldi requested review from BryanttV, MaferMazu, bmtcril, dwong2708, rodmgwgu and wgu-taylor-payne April 14, 2026 13:49

bmtcril reviewed Apr 14, 2026

View reviewed changes

rodmgwgu reviewed Apr 14, 2026

View reviewed changes

ccantillo force-pushed the crls/bulk-scope-role-assignment branch 2 times, most recently from 8a41ef9 to fdae762 Compare April 16, 2026 17:36

ccantillo added 4 commits April 16, 2026 12:47

feat: add bulk scope support to PUT /api/authz/v1/roles/users/

0a57aa2

Accept a new list field alongside the existing string, allowing role assignment across multiple scopes in one request while keeping full backward compatibility. Each response entry now includes a field.

refactor: simplify validated_scopes list in AddUsersToRoleWithScopeSe…

39b4a9c

…rializer

chore: bump version to 1.6.0 and update CHANGELOG

9d7c26b

refactor: extract scope/role validation into reusable helper in RoleS…

2d5ab84

…copeValidationMixin

ccantillo force-pushed the crls/bulk-scope-role-assignment branch from fdae762 to 2d5ab84 Compare April 16, 2026 17:51

dwong2708 reviewed Apr 16, 2026

View reviewed changes

rodmgwgu approved these changes Apr 16, 2026

View reviewed changes

dwong2708 approved these changes Apr 16, 2026

View reviewed changes

wgu-taylor-payne reviewed Apr 16, 2026

View reviewed changes

Comment thread CHANGELOG.rst Outdated

chore: update CHANGELOG for bulk scope role assignment

f47d361

Made-with: Cursor

ccantillo force-pushed the crls/bulk-scope-role-assignment branch from 2b39ec6 to f47d361 Compare April 16, 2026 18:27

mariajgrimaldi approved these changes Apr 16, 2026

View reviewed changes

mariajgrimaldi merged commit d852f05 into openedx:main Apr 16, 2026
8 checks passed

github-project-automation Bot moved this from Needs Triage to Done in Contributions Apr 16, 2026

Conversation

ccantillo commented Apr 13, 2026

Description

Changes

Backward Compatibility

Uh oh!

openedx-webhooks commented Apr 13, 2026

Uh oh!

mariajgrimaldi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ccantillo commented Apr 14, 2026

Uh oh!

bmtcril left a comment

Choose a reason for hiding this comment

Uh oh!

rodmgwgu commented Apr 14, 2026

Uh oh!

rodmgwgu left a comment

Choose a reason for hiding this comment

Uh oh!

ccantillo commented Apr 16, 2026

Uh oh!

rodmgwgu commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ccantillo commented Apr 16, 2026

Uh oh!

dwong2708 Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

rodmgwgu Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

dwong2708 Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

rodmgwgu left a comment

Choose a reason for hiding this comment

Uh oh!

dwong2708 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mariajgrimaldi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

rodmgwgu commented Apr 16, 2026 •

edited

Loading